系统数据库介绍
sysadmin 数据库
sysadmin 数据库包含具有以下内容的表。这些表中包含并组织调度任务和传感器,存储传感器收集的数据,还记录了调度工作和 SQL 管理 API 命令的结果。
缺省情况下,只授予用户 gbasedbt 对数据库 sysadmin 的访问权;可以授予其他用户对 sysadmin 数据库的访问权。
因为有些重要的数据库服务器组件使用它,您不能删除或更改 sysadmin 数据库。然而,如果 root dbspace 没有足够的空间存储任务属性和命令历史信息,您可以将 sysadmin 数据库从其缺省的 root dbspace 位置移除。移除 sysadmin 数据库请使用 reset sysadmin SQL 管理 API 命令:admin() 或 task() 。
重要: 在 sysadmin 移除数据库的过程中会将该数据库恢复到初次创建视的状态;所有的数据、操作历史和结果集表的信息都会丢失。只有内置任务、传感器和阈值保留在 sysadmin 表中。
Scheduler 表
Scheduler 表存储了 sysadmin 数据库中有关任务和传感器的五个表。它们分别是:ph_task 、ph_run 、ph_group 、ph_alert 和ph_threshold 。
Scheduler 是一个管理工具,它是数据库服务器可以在预定义的时间或有服务器内部驱动的时间执行功能和过程。它所使用的这五个表包含了自动运行的内置任务和传感器。您也可以通过往这些表中插入数据来添加您自己的任务和传感器。这些表有它们在下图中描述的列之间的关系。
Scheduler 表之间的关系:
ph_task 表
ph_task 表包含关于调度任务和传感器的信息。ph_task 表所包含内置任务和传感器是按计划自动运行的。
列 | 类型 | 描述 |
---|---|---|
tk_id | serial | 顺序任务 ID 由系统更新;不要修改 引用于 ph_alert 表中的 alert_task_id 列和表 ph_run 中的 run_task_id 列 |
tk_name | char(36) | 任务名称。在该列上有一个唯一索引确保没有两个名称是相同的。 引用于 ph_threshold 表中的 task_name 列 |
tk_description | lvarchar | 关于该任务的描述 |
tk_type | char(18) | 任务的类型: ● TASK: 以特定的时间和频率调用操作。 ● SENSOR: (缺省)一个从结果表中收集、存储和清除数据的任务 ● STARTUP TASK: 仅在服务器启动时运行的任务 ● STARTUP SENSOR: 仅在服务器启动时运行的传感器 |
tk_sequence | integer | 当前的数据收集号 由系统更新;不要修改 引用于 ph_alert 表中的 alert_task_id 列和 ph_run 表中的 run_task_seq 列 |
tk_result_table | varchar | 传感器用来收集数据的结果表名称。该表由 tk_create 列中的 CREATE TABLE 语句创建 |
tk_create | lvarchar | 用于创建传感器收集数据的结果表的 CREATE TABLE 语句。 表中必须有一名为 ID 的列,该列用来存储 tk_sequence 值。此值用来表示该行的年龄和清除行 |
tk_dbs | varchar(250) | 运行任务的数据库 缺省值 sysadmin 数据库 |
tk_execute | lvarchar | 要执行的 SQL 语句 命令长度限制在 2048 字节内 |
tk_delete | interval day(2) to second | 删除结果表中早于该时间间隔的数据 缺省值 1:00:00 (一天) |
tk_start_time | datetime hour to second | 任务或传感器启动的时间 缺省值 08:00:00 |
tk_stop_time | datetime hour to second | 该任务或传感器应停止运行的时间 数据库服务器在下一个有效日调度下一个执行 缺省值 19:00:00 。可以为 NULL ,表示没有停止时间 |
tk_frequency | interval day(2) to second | 该任务或传感器运行的频率 缺省值 1 (一天一次) |
tk_next_execution | datetime year to second | 该任务或传感器下次执行时间 如果已启动的任务或传感器已经运行,该值为 NULL 。当一个任务或传感器启动时,数据库服务器用 tk_start_time 、tk_stop_time 和 tk_frequency 列的值来计算此次时间。并根据 tk_monday 、tk_tuesday 、tk_wednesday 、tk_thursday 、tk_friday 、tk_saturday 和 tk_sunday 列来计算启动当天的星期数。例如:在 new_next_execution_time 比 current_next_execution_time 长的情况下, new_next_execution_time = current_next_execution_time + tk_frequency 。如果 tk_frequency 没有指示,任务只运行一次 |
tk_total_executions | integer | 该任务或传感器运行的总次数 由系统更新;不要修改 缺省值为 0 |
tk_total_time | float | 执行该任务或传感器所使用的时间 由系统更新;不要修改 缺省值为 0.0 秒 |
tk_monday | boolean | 该任务或传感器是否在星期一执行 缺省值为 T (true) |
tk_tuesday | boolean | 该任务或传感器是否在星期二执行 缺省值为 T (true) |
tk_wednesday | boolean | 该任务或传感器是否在星期三执行 缺省值为 T (true) |
tk_thursday | boolean | 该任务或传感器是否在星期四执行 缺省值为 T (true) |
tk_friday | boolean | 该任务或传感器是否在星期五执行 缺省值为 T (true) |
tk_saturday | boolean | 该任务或传感器是否在星期六执行 缺省值为 T (true) |
tk_sunday | boolean | 该任务或传感器是否在星期日执行 缺省值为 T (true) |
tk_attributes | integer | 标志 由系统更新;不要修改 |
tk_group | varchar(128) | 组名 必须与 ph_group 表中的列 group_name 的值相同。 缺省值 MISC |
tk_enable | boolean | 该任务或传感器是否已启用 缺省值为 T(该任务已启用) |
tk_priority | integer | 作业优先级,数值范围为 0- 5 ,数字越大级别越高。如果有几个作业要同时执行,则具有最高优先级的作业先执行。 缺省值为:0 (低优先级) |
ph_run 表
ph_run 表包含关于每个调度程序任务或传感器的运行方式和运行时间的信息。
列 | 类型 | 描述 |
---|---|---|
run_id | serial | 在执行期间生成的顺序 ID 由系统更新;不要修改 |
run_task_id | integer | 任务 ID 引用于 ph_task 表的 tk_id 列 |
run_task_seq | integer | 该任务或传感器的唯一顺序编号 引用于表 ph_task 的 tk_sequence 列 |
run_retcode | integer | 用户定义例程或存储过程的返回码或 SQL 命令的 SQLCode |
run_time | datetime year to second | 该任务或传感器的执行时间 |
run_duration | float | 执行改作业所使用的是案件(以秒为单位) |
run_ztime | integer | 服务器统计(onstat -z 命令)上次运行的时间 |
run_btime | integer | 服务器启动的时间 |
run_mttime | integer | 服务器的内部计数器 |
ph_group 表
ph_group 表包含有关调度程序组名的信息。它包含内置任务和传感器的分类组以及 MISC 中缺省的组。
列 | 类型 | 描述 |
---|---|---|
group_id | serial | 组 ID 由系统更新;不要修改 |
group_name | varchar(128) | 组的唯一名称 引用于 ph_task 表中的 tk_group 列 |
group_description | lvarchar | 组的描述 |
ph_alert 表
ph_alert 表包含调度程序的关于错误、警告或参考消息的信息。与内置任务和传感器有关的警报将自动添加到 ph_alert 表内。
列 | 类型 | 描述 |
---|---|---|
id | serial | 警报 ID 由系统更新;不要修改 |
alert_task_id | serial | 任务或传感器 ID 必须与 ph_task 表中 tk_id 列的值相同 事件报警的任务 ID 为 15 |
alert_task_seq | integer | 识别出哪些调度程序任务创建警报 由系统更新;不要修改 引用于 ph_task 表的the tk_sequence 列 |
alert_type | char(8) | 警报的类型: ● INFO (缺省的) ● WARNING ● ERROR 警报和事件报警的严重程度是由警报的类型和颜色综合确定的。 |
alert_color | char(15) | 警报的颜色: ● 绿色 (默认) ● 黄色 ● 红色 警报和事件报警的严重程度是由警报的类型和颜色综合确定的。 |
alert_time | datetime year to second | 产生警报的时间 由系统更新;不要修改 |
alert_state | char(15) | 指示对象当前所处的状态: NEW (默认)警报是新添加的,对该警报尚未发生任何其他操作 IGNORED 警报已由 DBA 确认,但未执行任何操作 ACKNOWLEDGED 警报已由 DBA 确认 ADDRESSED 警报已由 DBA 处理 |
alert_state_changed | datetime year to second | 最近一次状态被更新的时间 由系统更新;不要修改 |
alert_object_type | char(15) | 发生警报对象的类型: ● ALARM _ CHUNK ● DATABASE ● DBSPACE ● INDEX ● MISC (Default) ● SERVER ● SQL_STATEMENT ● TABLE ● USER |
alert_object_name | varchar(255) | 警报对象或事件报警类 ID 的名称 |
alert_message | lvarchar | 警报或事件报警的详细消息 |
alert_action_dbs | lvarchar(256) | 用于修正操作的数据库名称 缺省值为 sysadmin |
alert_action | lvarchar | 修正操作 可调用 SQL 脚本来修正该问题。该脚本必须符合所有多语句准备规则。 如果没有可用的操作,那么为 NULL |
alert_object_info | bigint | 事件报警的事件ID |
下表为 3 种不同类型的消息定义的警报颜色。
消息类型 | 绿色 | 黄色 | 红色 |
---|---|---|---|
Informative | 指示组件操作状态的状态消息 事件报警的严重程度为 1(不值得注意) | 重要的状态消息 事件报警的严重程度为 2 (可供参考) | 需要执行操作的状态信息 |
Warning | 自动处理的来自数据库的警告 | 需要处理的未来事件 事件报警的严重程度为 3(需要注意) | 即将发生预测的故障。需要立即执行操作 |
Error | 组件中的故障,由组件自身修正 | 组件中的故障,由组件自身修正,但可能需要 DBA 操作 | 组件中故障,需要 DBA 操作 事件报警的严重程度为 4(紧急)或 5(致命) |
ph_alerts 表显示了警报的信息和与之相关的任务和传感器的信息。
ph_threshold 表
ph_threshold 表包含关于调度程序任务阈值的信息。
ph_threshold 表包含了与内置任务和传感器相关联的内置阈值。例如:名为 COMMAND HISTORY RETENTION 的阈值决定了在 command_history 表中应保留的时间行长度。
列 | 类型 | 描述 |
---|---|---|
id | integer | 阈值 ID |
name | char | 阈值的名称 |
task_name | varchar | 与阈值相关联的调度程序任务名称 必须与 ph_task 表中 tk_name 列的值相同 |
value | lvarchar | 阈值的值 |
value_type | char | 值列的数据类型: ● STRING ● NUMERIC ● NUMERIC(p,s) |
description | lvarchar | 阈值的描述 |
结果表
结果表包含调度程序任务执行情况的历史数据。
大多数传感器创建一个新的表来存储它们的结果。表的名称在 ph_task 表的 tk_result_table 列中列出。表的结构是由 ph_task 表中 tk_create 列里的 CREATE TABLE 语句定义的。
当内置传感器以前缀 mon_ 启动时,它会自动创建结果表。
列 | 类型 | 描述 |
---|---|---|
ID | integer | 传感器的迭代顺序编号。必须在 $DATA_SEQ_ID 中设置 引用于 ph_run 表中的 run_task_seq 列 |
user columns | any | 可指定任意数据类型的列来保存由传感器返回的信息 |
command_history 表
command_history 表包含近 30 天内管理 API 函数已运行的所有 SQL 命令的列表。该表还会显示命令的结果。
command_history 表显示管理 API 的每一条 SQL 命令,并显示执行命令的用户的相关信息、命令执行的时间、命令、以及数据库服务器完成命令运行时返回的消息。
列 | 数据类型 | 描述 |
---|---|---|
cmd_number | serial | 每行的唯一 ID |
cmd_exec_time | datetime year-to-second | 命令的启动时间 |
cmd_user | varchar | 执行命令的用户 |
cmd_hostname | varchar | 执行命令的主机的名称 |
cmd_executed | varchar | 所执行的命令 |
cmd_ret_status | integer | 返回码 |
cmd_ret_msg | lvarchar | 返回消息 |
下表显示了示例命令和 command_history 表中关联的结果。
所执行的命令 (cmd_executed) | 返回的消息 (cmd_ret_msg) |
---|---|
set sql tracing on | SQL tracing on with 1000 buffers of 2024 bytes. |
create dbspace | Space 'space12' added. |
checkpoint | Checkpoint completed. |
add log | Added 3 logical logs to dbspace logdbs. |
要显示命令历史记录,请在 sysadmin 数据库中运行以下 SQL 语句:
SELECT * FROM command_history;
command_history 表的大小
依赖于所运行的管理 API 的 SQL 命令的数目。command_history 表可以扩展到很大。command_history 表中数据都有一个保留的时间周期。您可以通过更改 ph_threshold 表中的 COMMAND HISTORY RETENTION 行的 value 字段的来修改该时间周期。
您可以使用诸如 DELETE 或 TRUNCATE TABLE 之类的 SQL 命令从表中手动移除数据。
storagepool 表
storagepool 表在 sysadmin 数据库中,它包含了在 GBase 8s 实例存储池中的所有条目的信息。每个条目代表当自动扩展存储空间时,服务器可以使用的自由空间。
列 | 类型 | 描述 |
---|---|---|
entry_id | SERIAL | 存储池条目 ID |
path | VARCHAR (255) | 为服务器可以使用的文件、目录或设备需要额外的存储空间的路径 |
beg_offset | BIGINT | 初始的偏移量,以千字节为单位到设备的服务器可以开始分配空间 如果是一个目录的存储池信息,最终的偏移量值是 0 |
end_offset | BIGINT | 初始的偏移量,以千字节为单位到设备的服务器必须停止分配空间 如果是一个目录的存储池信息,最终的偏移量值是 0 |
chunk_size | BIGINT | 条目所分配的 chunk 的初始大小 |
status | VARCHAR (255) | 储存池条目的状态。状态值可以为: ● Active = 一个实用的存储池条目。服务器可以从此条目分配 chunk 。 ● Full = 存储池条目上没有可用空间。服务器不能从该条目分配 chunk 。 ● Error = 当服务器尝试从此条目分配 chunk ,存储池报错。 |
priority | INT | 当服务器通过存储池搜寻空间时,目录、文件或设备的优先级。服务器会先从高级别的条目分配空间,之后才是低级别的条目。 ● 1 = 高优先级 ● 2 = 中优先级 ● 3 = 低优先级 |
last_alloc | DATETIME (year to second) | 该条目最近一次被分配的时间 |
logid | INT | 当时最后使用此条目的当前日志的 ID 。服务器使用该标志和 logused 值在相同优先级别条目之间做出选择 |
logused | INT | 当时最后使用此条目的当前日志的位置。服务器使用该标志和 logid 值在相同优先级别条目之间做出选择 |
tenant 表
tenant 表在 sysadmin 数据库中,它包含了有关 tenant 数据库的信息。
列 | 类型 | 描述 |
---|---|---|
tenant_id | int | tenant 数据库的唯一 ID |
tenant_dbsname | varchar(128) | tenant 数据库的名称 |
tenant_resources | bson | tenant 数据库的属性 将这列切换成 JSON 去查看该属性 |
tenant_last_updated | datetime year to second | tenant 数据库最近一次更新的时间点 |
tenant_comment | lvarchar(2048) | tenant 数据库的详细信息 |
sysmaster 数据库
数据库服务器创建并维护 sysmaster 数据库。它类似于数据库的系统目录,数据库的系统目录在 GBase 8s SQL 参考指南 中描述。正如数据库服务器管理的每个数据库的系统目录对数据库中的对象和特权进行跟踪那样,每个数据库服务器的 sysmaster 数据库对有关数据库服务器的信息进行跟踪。
sysmaster 数据库包含了系统监视接口 ( SMI ) 表。SMI 表提供了有关数据库服务器的状态信息。可以查询这些表以识别处理瓶颈、确定资源的使用、跟踪会话或数据库服务器的活动等等。本章对这些表进行描述,它们与普通表稍有不同。
数据库服务器依赖于 sysmaster 数据库。请不要更改 sysmaster 中任何表和表中的任何信息。这种更改可能会导致不可预料和削弱性能的结果。
数据库服务器在其初始化磁盘空间时创建 sysmaster 数据库。数据库服务器创建具有未缓冲的日志记录的数据库。您不能删除数据库或其中的任何表,并且不能关闭日志记录。
作为在 UNIX™ 上的用户 Gbasedbt 或者 Windows™ 上的 Gbasedbt-Admin 组的成员,您可以在 sysmaster 数据库创建 SPL 例程。(也可以在 sysmaster 中的表上创建触发器,但数据库服务器从不执行那些触发器。)
联接 sysmaster 中的多个表可能返回不一致的结果,因为数据库服务器在联接过程中并不锁定这些表。可以将 sysmaster 表与其他数据库中的表进行联接。然而,要将 sysmaster 表与非日志记录数据库中的表进行联接,首先要使非日志记录数据库成为当前数据库。
buildsmi 脚本
当第一次启动数据库服务器时,它运行名为 buildsmi 的脚本,该脚本位于 etc 目录。该脚本构建支持 SMI 的数据库和表。数据库服务器需要大约 1750 页逻辑日志空间可用页以构建 sysmaster 数据库。
如果接收到指示您运行 buildsmi 脚本的错误信息,那么可能在数据库构建 SMI 数据库、表和视图时发生了问题。使用 buildsmi 时,将删除然后重新创建现有的 sysmaster 数据库。
在确保创建数据库过程中 sysmaster 数据库没有相关联接后,该脚本才能被执行。而且在 UNIX™ 上该脚本必须以 gbasedbt 用户的身份运行,在 Windows™上该脚本必须以 Gbasedbt-Admin 群组成员的身份运行。例如:若有一个调度程序的任务在 buildsmi 脚本开始时运行,且该程序试图去联接 sysmaster 中的任意一表,那么脚本就会运行失败。
buildsmi 脚本运行中产生的错误信息(在 UNIX )会被写入 /tmp/buildsmi.out 文件中,或者写入 %GBS_HOME%\etc\buildsmi_out 文件中(在 Windows 上)。
bldutil.sh 脚本
在第一次初始化数据库服务器时,在 UNIX™ 上运行名为 bldutil.sh 的脚本,或者在 Windows™ 上运行名为 bldutil.bat 的脚本。该脚本构建了sysutils 数据库。如果它失败,数据库服务器会在 tmp 目录中创建一个输出文件。该输出文件在 UNIX 为 bldutil.process_id ,在 Windows 上为 bldutil.out 。该输出文件中的消息反映脚本执行过程中发生的错误。